[Previous] [Next] [Index]
[Thread]
Re: HP e-commerce protocol
[a smaller distribution list]
Thanks to the open discussions and debates regarding the HP protocol
in these three days, I am now able to give a brief summary on what
I have learnt from, and what I have been influenced by, it. I would
like to post this summary because I absolutely agree with Hugo's
opinion: the issues that we are discussing are *very important*.
Please bare in mind that I don't mean to give a conclusion for the
discussions; it's only a milestone summary.
In this summary, I will highlight some features possessed in the
HP protocol which I believe to have demonstrated the potential in
influencing the 3KP protocol of IBM. In fact, I find myself also
getting benefit from the discussions and the 3KP protocol and will
accept some good points to augment the HP protocol.
First of all, I find there is a need to explicitly dismiss the
following published misunderstanding: "the HP protocol is vulnerable
to the man-in-the-middle-attack because it uses the Diffie-Hellman key
exchange technique." The HP protocol thwarts this attack by letting
the bank digitally sign the material for ticket key agreement. For a
simple and clear explanation of this, please see the questions and
answers in the HP webpage:
http://www.hpl.hp.co.uk/projects/vishnu/main.htm; for a slightly more
detailed mathematical description, please read the HP protocol in the
same webpage.
Now, it's natural to ask: since the banks use public keys, then does
it mean that the HP protocol still relies on using public key
certification infrastructure? No. The reason why the public key
certification infrastructure is needed in the area of application and
becomes troublesomely complex (and hance could be expensive) is
because the public keys are used by small users, especially,
individuals. Banks are well-established parties; to make their public
keys equally well-know is a much much easier and cheaper job. I will
get back to this point later in this summary.
Conjuncting the point in the above paragraph with my responses to
Hugo's messages (hugo@watson.ibm.com) yesterday (to quote below), the
HP protocol does indeed eliminate the need of employing the expensive
public key certificate infrastructure. (quoting my messages below):
> I won't mind the names. However, I would like to re-emphasize my point
> that I have made in the webpage: the HP protocol uses *asymmetrical*,
> *non-public* keys: the *asymmetricity* gives the non-repudiation
> service, and the *non-publicness* cuts the need of employing complex
> and expensive CAs.
> ......
> In page 12 of my paper, I sketched a cheap method for the bank to
> maintain auditing records which (1) protects the integrity between a
> one-way hashed password and an end-user; and (2) forces the bank and
> the users to stick to using correct passwords. That method works on
> the basis of the following scenario: the bank uses or certifies the
> user's hashed password on the evidence of the user's signature which
> is made in the previous correct transactions. Such records sustain a
> hostile examination in the court. I think this forms one of the
> reasons that *one* bank alone qualifies to provide authentication
> services.
Note that the term *non-publicness* above does not mean the secrecy of
that key; it mearly means that the usage of that key is specific. The
specificness leads to an easy way for the bank to produce quality
auditing records. I am delighted that the importance of this
"CA-lessness" has been recognized as a result of the discussions;
quote Hugo's message here:
> Date: Tue, 16 May 95 13:06:39 EDT
> From: hugo@watson.ibm.com
> Subject: HP e-commerce protocol
>
> In response to notes by Wenbo and Hal Finney let me just point out to
> minimal changes to 3KP that will provide a "CA-less" solution.
>
> Just take away from the protocol any mentioning of certificates (denoted
> $CERT_C , CERT_M , CERT_A$).
> Assume now that the financial institution (e.g, the acquirer or issuer bank)
> keeps a database of users and their corresponding public keys (users may be
> customers or merchants), as in the case of the HP protocol.
>
> Take away the sending of merchant's signature to the customer.
> What you get is a CA-less protocol with all the properties claimed in
> the HP-protocol.
The discussions also give me an important influence. It is about the
transaction model of HP protocol. This is meanly due to
Mark H Linehan's comments <linehan@watson.ibm.com> quoted below:
> Date: 16 May 95 13:06:28
> From: Mark H Linehan/Watson/IBM Research <linehan@watson.ibm.com>
> Subject: Re: HP e-commerce protocol
>
> Some comments about your protocol, and some comparisons with the iKP design of
> my colleagues here at IBM Research:
> ......
> 3. Steps III and IV of your protocol involve signatures under public keys.
> There is no discussion of how the recipients of these messages may know the
> public keys required to verify the signatures. In particular, step IV's
> message is from Fc to M, which implies that all merchants must know the public
> keys of all customer financial institutions. This is unrealistic.
Although I have proposed a very general transaction model for the HP
protocol which generalizes the finantial institutions as the bank of
the client (Fc) and that of the merchant (Fm), however, thanks to
Mark Linehan's comments above, I would think that these two banks are
not in equivalent possitions; the bank Fm can be a credit card
company. It's easy for a credit card company to know the client's
bank Fc even if it is a local branch of a normal bank. The credit card
company Fm is also responsible for distributing the public keys of
Fc's to merchants. This distribution can be done off-line, or in
the case when the merchant meets Fc in the first time, on-line. The
idea in this paragraph also owes the following comments from Hal
Finney (quoting below):
> Date: Tue, 16 May 1995 09:05:13 -0700
> From: Hal <hfinney@shell.portal.com>
> Subject: Re: HP e-commerce protocol
> ......
> not have certificates. In HP, the user and the issuer bank share, not a
> PIN, but in effect a Diffie-Hellman public key. As in 1KP, we leave out
> the mechanism by which they come to share this information, but I will
> note that it should be easier than with 1KP since the information does
> not have to be kept secret, only transferred reliabily. 1KP requires
> both secrecy and reliability for the exchange of the PIN.
>
> Now, the inter-bank communication in HP is complicated and I haven't
> fully figured it out. But it seems to me that the use of a public key
> rather than a shared secret could be an easy addition to 1KP to provide
> non-repudiation without adding the infrastructure of CA's. Where an
> issuer bank today authorizes a user by just checking his PIN, it could
> instead check a DH signature on a hash of the message, timestamp, etc.
> The issuer bank is no more acting as a CA in this system than it is in
> 1KP; it is simply using a different protocol to authorize the user.
Below I would like to say something about the scalability of the HP
protocol. The HP protocol uses on-line banks. I don't think this forms
a big penalty nowadays. The problem seems to be so small if the
headquarter bank of the local branch Fc also keeps a copy of the
one-way hashed passwords of the Fc's clients. Then, during the time
when Fc switches off, the headquarter will act on behaf of Fc
(perhaps, the amount of money to be transacted should be limited in
the case if the headquarter does not know the healthy info of the
account in question). The good scalability of the centrally stored
keys in the HP protocol permits this scenario of headquarter acting
for the local branch. Basically, I will not imagine on-line bank to be
a problem when we are talking about the use of an on-line shop.
Finally, I would like to comment the issue of exportation. This is to
respond the following comments from Mark H. Linehan:
> Date: 16 May 95 13:06:28
> From: Mark H Linehan/Watson/IBM Research <linehan@watson.ibm.com>
> Subject: Re: HP e-commerce protocol
> ......
> 4. You argue an advantage in "international compatibility" because you don't
> use encryption. However, both iKP and CyberCash have received U.S. export
> permission for schemes that involve RSA encryption of limited amounts of order
> information. I don't know how France and Russia and any other countries that
> control encryption technology will react, but I would suggest that they may
> also accept limited usage of encryption. So "international compatibility" is
> not necessarily a unique advantage of the HP protocol.
Please accept my congratulations on your receipt of the big brother's
permission:-). No doubt, the uniqueness of the permission determines
"a unique advantage" of the iKP protocol:-)
Now back to the business.
A ccording to the "Summary of Export Rules for Products Containing
Cryptographic Functions", Stephen D. Crocker, July 26, 1992 (recently
re-posted by Robert W. Shirey of MITRE Corp. on
owner-www-security@ns2.rutgers.edu, attached in the end of this
message), we know that for exportation of RSA from the US to the rest
of the world other than Canada, for the use of encryption, is coded
"G", which means "An export license is required and generally will NOT
be granted". However, if the encryption is used by banks, then the
code is "F", which means "An export license is required and is
generally granted provided the modulus does not exceed 512 bits".
I believe what you get is under the code "F". I am *very* worrying
the strength of the RSA modulus used in iKP. It is known that the
original implementation of DSS gets a critique that its 512-bits
modulus is too short for long-term security. In response to this
criticism, NIST made the key size variable, from 512 bits to 1024
bits. Please note that factoring an RSA modulus has an equivalent
computational complexity to that of computing a discrete logarithm
(the security basis of DSS) with the same length of modulus. You see,
while keeping himself secure, the big brother only permits you a
second-class security.
Things are totally different in the HP protocol. We do not look at the
big brothers' faces (yet some faces, such as French's, still behind
masks), and we have the security as we wish. The modulus used in our
modular exponentiation can have the same length as, or even longer
than, that of the bigest brother's in the world. Well, I guess I
should stop now; the big brother is watching at me.
Cheers,
Wenbo
Attaching the exportation control info
From: shirey@mitre.org (Robert W. Shirey)
Subject: Re: Re- Hierarchies and Webs of [trust]
Sender: owner-www-security@ns2.rutgers.edu
Precedence: bulk
Errors-To: owner-www-security@ns2.rutgers.edu
Status: RO
I GUESS THERE ARE ENOUGH NEW PEOPLE ON THIS LIST TO MAKE IT WORTH AGAIN
SENDING OUT STEVE CROCKER'S "CRIB SHEET" ON EXPORT CONTROLS. -ROB-
Summary of Export Rules for Products
Containing Cryptographic Functions
Stephen D. Crocker
July 26, 1992
For use within/by
Security Algorithm U.S. & Banks & All
Service Used Canada U.S. Subs Other
Integrity, RSA A C C
Signature &
Access Ctl DES A C C
Other A C C
Symmetric
Key RSA B F F
Management
DES B E E
Other B E E
Symmetric
Encryption RSA B G G
DES B D G
Other B F F
Symmetric
Key
A No restriction.
B No restriction. A label is recommend which warns that export of
the product requires a license.
C A license is required. A general Commerce Department commodity
license is available except for shipments to Eastern bloc
countries. Individual licenses are needed for shipment to Eastern
bloc countries and are generally granted.
D A State Department license is required and will generally be
granted.
E An export license is needed. Each application will be examined on
a case-by-case basis. For some products, a Commerce Department
commodity license may be available.
F An export license is required and is generally granted provided
the modulus does not exceed 512 bits.
G An export license is required and generally will NOT be granted.